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FOREWORD 


APJ,  under  contract  to  HQs,  AMCCOM,  has  initiated  the 
automation  of  the  LSA  Tasks  (MIL-STD-lSSS-l)  and  the  assessment 
of  the  ILS  elements  (AR  700—127)  .  A  major  goal  is  to  unify 
military  amd  contractor  approach  to  the  performance  of  ILS  and 
LSA. 


Detailed  to  meet  all  requirements  of  ILS  and  LSA,  the 
automated  process  will  continue  to  provide  full  flexibility  in 
selecting  tasks  and  elements  to  be  addressed  at  each  life  cycle 
stage.  At  the  same  time  it  will  insure  that  the  application  of 
each  task  element  is  consistent  with  prescribed  Army  policies 
and  procedures. 

This  report  consolidates  the  Structured  Analysis  and 
Structured  Design  tinder  one  cover  for  the  respective  LSA  Tasks. 
Structured  Analysis  provides  a  logical  model  of  the  method  to 
perform  am  LSA  Task.  This  logical  model  facilitates  the 
development  of  a  Structured  Design  that  provides  the  detailed 
procedures  to  perform  the  analysis.  Both  the  logical  model  and 
detailed  procedures  are  used  to  develop  the  application  software 
programs  which  will  be  provided  to  Government  amd  contractor 
personnel  to  assist  in  the  performance  of  the  LSA  Task. 

Included  in  this  report  are  the  Data  Flow  Diagrams  (DFDs) 
for  LSA  Subtask  303.2.11,  "Survivability  amd  Battlefield  Daunage 
Repair  Characteristics"  and  the  corresponding  descriptions  of 
the  processes,  data  flows,  data  stores,  amd  external  entities 
identified  on  each  DFD  (Annex  B)  .  In  addition  the  DFDs  are 
further  developed  into  step  by  step  procedures  (Annex  C)  which 
identifies  how  to  use  the  data  to  carry  out  the  processes  which 
ultimately  lead  to  accomplishing  the  LSA  Subtask. 

To  assist  managers  in  planning  and  controlling  this  task. 
Venture  Evaluation  Review  Technique  (VERT)  Batch  Input  Files  are 
provided  (Annex  D)  .  These  VERT  tools  provide  government 
agencies  with  complete  packages,  that  cover  both  technical  and 
managerial  aspects  of  a  task,  to  give  to  contractors .  This 
approach  establishes  a  standardized  form  of  communication  and 
m2magement  between  contractors  performing  the  task  and 
government  personnel  reviewing  the  task. 

To  view  this  work  in  context.  Annex  E  of  this  report  also 
presents  a  brief  overview  of  Structured  Analysis  and  its  place 
in  the  overall  systems  development  process .  The  overview,  and 
certain  portions  of  the  introductory  text  are  repeated  verbatim 
in  every  report  in  this  series  so  that  each  report  is  free 
standing. 
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EXECUTIVE  SUMMARY 


LSA  SUBTASK  303.2.11 

SURVIVABILITY  AND  BATTLE  DAMAGE  REPAIR  CHARACTERISTICS 


The  American  Power  Jet  Company  (APJ)  is  under  contract  to 
the  Army  Armament  Munitions  and  Chemical  Commcind  (AMCCOM)  to 
provide  "how  to"  procedures  for  selected  ILS  and  LSA  tasks.  The 
results  of  this  effort  are  a  series  of  Structured  System 
Analysis  auid  Structured  System  Design  reports . 

The  intent  of  this  work  is  to  be  compatible  with  CALS, 
LOGPARS,  amd  other  similar  efforts  to  enhance  performance, 
training,  and  automation.  Our  basic  structure  facilitates  the 
downstreaun  application  of  Artificial  Intelligence  and 
streamlining  of  these  critical  functions. 

STRUCTUPEO  SYSTEM  ANALYSIS 

Excelerator,  a  Computer  Aided  Software  Engineering  (CASE) 
tool,  was  used  to  prepare  the  Structured  System  Analysis.  Each 
LSA  Task  is  modeled  by  a  series  of  Data  Flow  Diagrams  (DFDs)  , 
depicting  activities  and  accompanying  data  flows  needed  to 
produce  intermediate  or  final  products.  Complex  activities  are 
"broken  down"  or  "exploded"  into  lower  level  data  flow  diagrauns. 

Bach  DFD  caui  contain  four  types  of  objects: 
o  Processes  or  activities 

o  Data  Flows  -  inputs  to  a  process  or  data  output 
generated  from  a  process 

o  Data  Stores  -  identifies  sources  for  the  data 
o  External  Entities  -  indicates  who  to  contact  for 
guidance . 

Each  object  is  described  either  by  developing  detailed 
procedures  or  identifying  its  data  content .  The  object 
descriptions  are  placed  in  a  Data  Dictionary  which  is  built-up 
as  the  Data  Flow  Diagrams  are  expanded,  detailed,  euid  eventually 
completed. 

STRUCTUPED  SYSTEM  DESIGN 

The  Structured  Design  amplifies  the  processes  and  data 
flows  developed  in  the  Structured  Analysis  into  procedures  used 
to  accomplish  the  LSA  Tasks  and  Subtasks.  The  Analysis  provides 
the  method  and  the  Design  implements  it . 
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In  addition  to  the  narrative  portions  of  the  Structured 
Design,  "Input  Screens"  are  developed  for  each  process  or  set  of 
processes .  The  charts  structure  and  organize  the  data  needed  to 
perform  a  LSA  task  and  make  decisions  on  Weapon  System 
supportaQjility .  By  formalizing  the  data  requirements  in  this 
manner,  a  standard  set  of  output  reports  caui  be  specified. 

AUTOMATION 

The  Structured  Design  material  can  of  course  be  used  in  a 
manual  fashion.  However,  automation  of  the  task  achieves 
several  objectives: 

The  analyst  performing  the  LSA  Task  is  taken  through  a 
series  of  automated  steps  leading  to  a  successful  result. 
More  time  is  spent  actually  doing  the  work  instead  of 
deteinoining  what  must  be  done  next.  Help  is  available  at 
every  step  to  guide  the  analyst  through  the  task. 

The  information  is  organized  so  that  productivity  improves 
because  more  time  is  spent  gathering,  analyzing,  and 
interpreting  the  data  instead  of  tedious  record  keeping. 

All  data  is  structured  and  stored  by  the  software  so  it  can 
be  easily  retrieved,  edited,  and  added  to. 

Output  reports  are  standardized  through  a  report  generation 
facility  using  preprogreunmed  report  formats.  Efficiency 
improves  since  the  analyst  is  relieved  of  the  burden  of 
writing  amd  formatting  reports.  Decision  makers  receive 
reports  in  fauniliar  formats  so  the  most  significant 
sections  can  be  quickly  found. 

A  large  volume  of  data  will  be  captured  auid  stored  over  a 
period  of  time,  creating  a  large  "knowledge  base".  This 
knowledge  base  provides  a  body  of  procedures,  sources, 
data,  and  lessons  learned  for  an  analyst  to  query  and  apply 
against  a  new  or  update  auialysis  effort.  This  availc±>le 
information  forms  the  of  basis  eui  Artificial  Intelligence 
(AI)  expert  system. 

Automation  of  selected  LSA  subtasks  are  being  prototyped  to 
demonstrate  the  principles  involved  and  gain  user  experience . 
Although  fully  general,  all  prototypes  are  designed  for  ready 
development  and  adaptation  to  specific  weapon  systems . 

LSA  SOBTASK  303.2.11  DESCRIPTION 

The  concept  of  Survivability  and  Battle  Deunage  Assessment 
and  Repair  is  to  develop  wartime  procedures  that  return  disabled 
equipment  to  an  operational  commander  expeditiously.  The  task 
is  designed  to  allow  key  weapon  and  materiel  systems  to  be 
restored  to  partial,  if  not  full,  functional  capability  or  at 
least  be  capaOole  of  self-recovery  when  they  are  damaged  or  fail 
on  the  battlefield. 
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It  isolates  components  that  are  design  deficient  in  areas 
of  survivability  and  repairability  from  those  that  allow 
expeditions  repair  procedures  to  be  developed.  It  also 
recommends  design  modifications  that  improve  the  components 
survival)  il it y  amd  battle  resilience  characteristics .  For 
components  that  allow  expeditious  repair  in  the  battlefield 
environment,  the  task  develops  simple,  speedy  and  effective 
repair  procedures .  These  procedures  may  be  temporary  and  may 
not  restore  the  full  performance  capability  of  the 
system/ subsystem . 
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INTRODUCTION 


purpose 

The  purpose  of  this  report  series  is  to  present  the  results 
of  the  APJ  Structured  Analysis/Design  under  Contract 
DAAA21-86-D-0025  for  coordination  with  the  AMCCOM  Prograuti 
Memager  prior  to  in-depth  progrcunming  of  ILS  and  LSA  functions 
and  processes ,  LSA  Task  303  "Evaluation  of  Alternatives  & 
Trade— Off  Analysis",  ("LSA  Subtask  303.2.11,  "Survivability  & 
Battlefield  Damage  Repair  Characteristics")  is  addressed  in  this 
report . 

BACKGROUND 

The  Department  of  the  Army  has  a  requirement  for  management 
control  over  contractor  and  Government  agency  response  to  the 
requirements  of  AR  700—127,  "Integrated  Logistic  Support",  and 
MIL-STD-1388-1,  "Logistic  Support  Analysis".  Hqs  AMCCOM  has 
initiated  action  to  structure  each  of  the  LSA  tasks,  the 
assessment  of  each  ILS  element,  the  form  of  the  results,  and  the 
detailed  processes  to  insure  consistency  with  current  Army 
policies,  procedures,  and  techniques. 

This  approach  (undertaken  by  AMCCOM  and  APJ)  will  insure 
uniformity  in  efforts  and  products,  reproducibility  of  analyses, 
and  a  well-defined  structure  which  can  be  coordinated  aunong  all 
participants  in  the  logistic  process  to  arrive  at  common 
iinderstanding  auid  procedures . 

SCOPE 


This  report  summarizes  the  results  of  the  Structured 
Analysis  of  the  identification  of  LSA  Task  303  "Evaluation  of 
Alternatives  &  Trade-Off  Analysis",  LSA  Subtask  303.2.11, 
"Survivability  &  Battlefield  Damage  Repair  Characteristics",  and 
presents  the  associated  Data  Flow  Diagrauns  (DFDs)  developed  from 
the  Structured  Analysis  and  the  corresponding  procedures 
developed  in  the  Structured  Design.  The  portions  of  the  Data 
Dictionary  relating  to  the  DFDs  for  this  LSA  Subtask  includes 
the  labels,  naunes,  descriptions.  Processes,  Data  Flows,  Data 
Stores,  auid  External  Entities.  (The  Data  Dictionary  is  a 
"living  doc\ament"  that  evolves  through  the  analysis  and  design 
process) .  The  Structured  Design  portion  of  this  report  develops 
the  Processes  and  Data  Flows  developed  in  the  DFDs  into 
procedures  which  are  used  to  accomplish  the  LSA  Tasks .  The  DFDs 
provide  the  method  and  the  Design  implements  it,  by  formulating 
a  guide  for  programmers  to  write  software  applications. 
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This  report  presents  a  brief  overview  of  Structured 
Analysis  and  its  place  in  the  overall  systems  design  process  to 
assist  the  reader  who  may  not  be  fully  brrefed  on  the  symbols 
and  conventions  used.  It  is  supported  by  Annex  E,  which  defines 
each  element  in  Structured  Analysis. 

LSA  SUBTASK  303.2.11  DESCRIPTION 

The  "Survivability  and  Battlefield  Damage  Repair 
Characteristics"  Trade-Off  Analysis  identifies  critical 
components  for  each  system/ subsystem  during  operation  on  the 
Battlefield.  This  subtask  identifies  systems  that  are  deficient 
in  terms  of  battle  survivability  and  resilience  and  display  poor 
battlefield  repair  characteristics. 

A  case  in  point  is  to  differentiate  between  combat 
resilience  and  regular  maintainability.  The  two  features  that 
distinguish  combat  resilience  from  maintain2d3ility  are  location 
and  time.  Combat  resilience  is  a  characteristic  that  is 
designed  into  equipment  to  allow  partial,  if  not  full, 
restoration  of  functional  capadjility  quickly  when  an  item  fails 
or  is  damaged  on  the  battlefield.  Repairs  must  be  made  quickly, 
preferably  at  the  location  of  the  breakdown,  so  that  the 
equipment  can  continue  its  original  mission  or  undertake  a  more 
limited  mission  which  may  be  self  recovery. 

The  approach  to  this  task  categorizes  system  components  as 
either  candidates  for  design  change  to  improve  their 
survivaJaility  and  battle  resilience  characteristics  or  for  the 
esteiblishment  of  expedient  maintenance/repair  techniques  in  the 
battlefield  enviroiuaent .  Components  requiring  redesign  are 
identified  where  the  design  is  deficient  due  to  inability  to 
develop  expedient  maintenauice/repair  procedures.  The  other 
aspect  of  this  task  relates  to  the  recommendation  of  the  optimvim 
repair  method  to  be  adopted  in  the  battlefield  in  order  to 
restore  the  System/Subsystem  to  its  full  operational  capaQsility. 

This  task  provides  the  processes  and  methods  required  to 
develop  and  extract  the  data  and  information  needed  -  including 
the  testing  requirements  and  source  data  used  to  develop 
docximents  for  use  in  the  field. 

The  LSA  Task  Description  with  associated  task  inputs  and 
outputs  is  extracted  from  MIL-STD-1388-1A  and  is  included  as 
Annex  A. 
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APPROACH 


The  APJ  approach  to  Structured  Analysis  and  Structured 
Design  of  an  LSA  Subtask  is : 

1.  Scope  the  Subtask  defined  in  MIL-STD-1388-1A  with  the 
overall  task  and  determine  its  relationship  with  other  LSA 
Tasks . 

2.  Review  all  pertinent  documentation  (e.g.,  AR's,  MIL- 
STDs,  etc.)  applica±>le  to  the  specific  topic, 

3.  Prepare  the  Top  Level  DFDs  in  context  of  the  Subtask, 
and  develop  lower  level  DFDs  to  further  elciborate  any  complex 
process  identified  in  the  top  level  DFD. 

4 .  Complete  the  Data  Dictionary  portion  of  the  Analysis 
by  describing  all  Processes,  Data  Flows,  Data  Stores  and 
External  Entities . 

5.  Apply  staff  experience  in  Logistic  Support  Analysis  to 
assure  that  the  topic  has  been  exhaustively  addressed. 

6 .  From  the  completed  DFDs  prepare  the  step  by  step 
procedures  that  form  the  structured  design. 

7 .  Review  Data  Item  Description  and  other  applicable 
material  to  develop  output  reports. 

8 .  If  required  revise  DFDs  and  Data  Dictionary  based  on 
preparation  of  detailed  procedures. 

9.  Validate  results  in  discussions  with  Army  activities 
and  personnel  directly  involved  in  the  applicable  or  related  LSA 
tasks . 

NOTE:  Structured  Analysis  and  preparation  of  Data  Flow 

Diagrams  (DFDs)  was  further  assisted  by  the 
application  of  Structured  Analysis  software.  Licensed 
by  Index  Technology  Corporation,  Excelerator  provides 
for  automated  tracking  of  names,  labels,  descriptions, 
multiple  levels  of  detail  in  the  Data  Flow  Diagrauns, 
cind  industry  standards  in  symbols  and  diagramming 
practices . 

LSA  SUBTASK  303.2.11  -  SURVIVABILITY  AND  BATTLEFIELD  DAMAGE 

REPAIR  CHARACTERISTICS 

The  Data  Flow  Diagram  is  a  tool  that  shows  the  flow  of 
data,  (i.e.,  data  flows  from  sources)  and  is  processed  by 
activities  to  produce  intermediate  or  final  products. 
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The  DFD  provides  a  useful  and  meaningful  partitioning  of  a 
system  from  the  viewpoint  of  identification  and  separation  of 
all  functions,  actions,  or  processes  so  that  each  can  be 
introduced,  changed,  added,  or  deleted  with  minimal  disruption 
of  the  overall  program,  i.e.,  it  emphasizes  the  underlying 
concept  of  modularity  and  identifizJDle  tramsformations  of  data 
into  actionable  results . 

A  series  of  three  (3)  DFDs  have  been  developed  to  structure 
the  LSA  sxibtask  relative  to  operations  and  other  support 
functions : 

1.  303.2.11  SurvivadDility  and  Battle  Oaunage  Repair 

Characteristics 

2.  303. 2. 11. 2A  Evaluate  Critical  Components 

3.  303.2.11.5A  Recommend  Repair  Method 

Each  DFD  is  keyed  to  the  specific,  task  through  the 
identification  number  assigned  in  the  lower  right  hand  box.  The 
Alpha  codes  indicate  the  level  of  indenture  or  explosion  below 
the  top  level,  i.e.,: 

Top  Level . LSA  DFD  303.2.11 

First  Indenture . LSA  DFD  303 . 2 . 11 . 2A 

Each  DFD  makes  reference  to  the  basic  LSA  task  it 
addresses,  as  well  as  the  level  of  indenture  (explosion)  of  the 
DFD.  For  example,  the  first  or  top  level  DFD,  ”303.2.11", 
refers  to  the  section  in  MIL-STD— 1388-lA  which  describes  the 
review  items.  One  of  the  processes  (bubbles)  on  the  top  level 
diagraun  (303.2.11.2)  is  expanded  and  identified  as 
"303. 2. 11. 2A",  a  second  level  of  "303.2.11.2"  (Alpha  "A" 
indicates  the  second  level) . 

Four  standard  symbols  are  used  in  the  drawing  of  a  DFD  (see 
Annex  E  -  Figure  1) . 

A  copy  of  each  DFD  is  presented  in  Annex  B  accompanied  by 
the  Data  Dictionary  elements .  Each  entry  made  in  the  DFDs  has 
a  corresponding  entry  in  the  Data  Dictionary. 

This  presents  only  those  Data  Dictionary  entries  necessary 
for  the  coordination  of  the  overall  concept  and  details  of  the 
processes.  To  facilitate  review  of  the  Data  Flow  Diagrams,  a 
description  of  all  the  entities  within  them  (i.e.  Processes, 
Data  Flows,  Data  Stores  and  External  Entities)  is  provided.  As 
noted  a±>ove,  they  will  continue  to  evolve  and  be  expanded  in  the 
System  Design  phase. 
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VERT  DIAGRAMS 


The  Venture  Evaluation  Review  Technique  (VERT)  was 
developed  as  a  network  auialysis  technique  to  facilitate 
management  decision  making.  It  allows  systematic  planning  and 
control  of  the  prograim  and  enadsles  mauiagers  to  find  solutions  to 
real  life  meinagerial  problems .  The  VERT  Diagreuns  and  Batch 
Input  Files  for  this  task  cam  be  found  in  Annex  D .  In  order  to 
understamd  how  these  Input  Files  were  developed,  a  brief 
discussion  of  the  methodology  used  is  provided.  The  same 
explaination  is  repeated  verbatim  in  every  report . 
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ANNEX  A 


LSA  TASK  303 

EVALUATION  OF  ALTERNATIVE  AND 
TRADE-OFF  ANALYSIS 


ANNEX  A 
LSA  TASK  303 

EVALUATION  OF  ALTERNATIVES  AND  TRADE-OFF  ANALYSIS  V 


303 . 1  PURPOSB  To  determine  the  preferred  support  system 
alternative (s)  for  each  system/ equipment  alternative  and  to 
participate  in  alternative  system  trade-offs  to  determine  the 
best  approach  (support,  design,  and  operation)  which  satisfies 
the  need  with  the  best  balance  between  cost,  schedule, 
performance,  readiness,  and  supportadsility . 

303.2  TASK  DESCJUPTION 

303.2.11  Conduct  evaluations  and  trade-offs  between 
system/ equipment  alternatives  and  survivability  and  battle 
dzunage  repair  characteristics  in  a  combat  environment. 


1/  Abstracted  verbatim  from  MIL-STD-1388-1A,  April  11,  1983, 
Pages  36-37. 
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Nanie 


Label  Description 


303.2.11.1 


303.2.11.2 


303.2. 11, 2A1 


303.2. 11.2A2 


303.2.11.2A3 


SELECT  PURPOSE:  To  select  Systeo/Sobsystan  tjpe  to  be  analyzed  in  this 

SYSTEM/  iteration  of  the  LSA  SobtasX.  The  Systan/SobsysteB  so  selected  oust 
SUB8YSTQ1  conforn  to  the  {forX  Breakdown  Structure  (HBS)  set  forth  in  MIL-STD-881. 
Source  of  Data: 

Approved  or  Unapproved  RFP's 
Approved  or  Unapproved  IFB's 
Progress  Reports 

EVALUATE  PURPOSE:  To  evaluate  the  ccsiponents  of  the  System/SubsysteB  for 

COffONEtns  their  criticality  in  perforaing  the  functional  requirenents. 

FOR  THEIR  Source  of  Data: 

CRIIICALIT  Required  Operational  Characteristics 

Y  Functional  Requireaents  Data 

Reliability  Data 
Failure  Rate  Data 
Engineering  Drawings 
Hardware  Specifications 
Itea/Equipnent  Specifications 
Iten/Eqnipaent  Missions  and  Functions 

r 

ASSESS  HD  PURPOSE:  To  review  the  survivability  and  vulnerability 

RESILIENCE  characteristics  of  the  Systea/Subsystea  and  deteraine  the  extent  to 
CHARACTER-  which  its  coaponents  are  resilient  to  battlefield  daaage. 
isncs  Source  of  Data: 

Engineering  Drawings 
Itea/Equpaent  Specifications 

IDENTIFT  PURPOSE:  To  deteraine  the  extent  to  which  a  coaponent  is  critical  to 

CRITICAL  the  operation  of  the  Equipaent/Systea/Subsystea.  In  doing  so  the 
COMPONENTS  analyst  anst  take  into  account  the  survivability  characteristics  of  the 
coaponent  and  the  functional  requireaents  of  the  Systea/Subsystea. 

Source  of  Data: 

Required  Operational  Characteristics 
Functional  Recpiireaents 
Reliability  Data 
Failure  Rate  Data 

DETERMINE  PURPOSE:  This  process  detezoines  the  functions  that  would  be  lost 

FUNCTION  due  to  the  various  types  of  daaage  that  could  occur  to  the 
LOST  DUE  Systea/Subsystea/Coaponent  when  operating  in  the  battlefield 
TO  DAMAGE  environaent.  This  process  further  exeaplifies  the  criticality  of  the 
coaponent  in  the  performance  of  its  operational  functions. 

Source  of  Data: 

Required  Operational  Characteristics 
Functional  rqeuireaents  Data 
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303.2.11.3  CONDUCT  PURPOSE:  This  process  assesses  the  possible  types  of  damage  that 

DAMAGE  could  be  caused  to  the  critical  components.  The  d^ge  assessment  must 
ASSESaffiNT  segregate  Systems/Subsytou/Critical  Components  that  are  poorly 

designed  for  surriTability  and/or  battlefield  repair  fron  those  that 
are  resilient  to  battle  damage  and  capable  of  being  r^aired  on  the 
battlefield. 

Source  of  Data: 

Engineering  Drawings 
Itea/Equipment  Specifications 
Itea/E^ipment  Missions  and  Functions 
AMC-R-700-27  LeTel  of  Ri^air  Analysis  Program  (LORA) 

303.2.11.4  RECOtMEMD  PURPOSE:  To  reconend  design  changes  that  must  be  implemented  to 

DESIGN  make  the  System/Subsystem/Component  resilient  to  battle  damage  and  make 
CHAIKZS  it  repairable  on  the  battlefield. 

Source  of  Data: 

Engineering  Drawings 
Item/Eqnipment  Specifications 
Item/Equi^ent  Missions  and  Functions 

303.2.11.5  RECQtfSND  PURPOSE:  This  process  evaluates  the  available  repair  alternatives 

REPAIR  to  restore  as  much  of  the  System/Subsystea/Critical  Component's 
MEIHODOL06  operational  capabilities  as  possible.  Having  evaluated  the  various 

T  alternatives  the  analyst  is  to  recoannd  the  optimum  method  of  repair 

for  the  component.  The  analyst  must  also  state  the  resources  required 
to  undertake  the  r^air  in  terms  of  required  tools,  manpower,  tiu  etc. 
Source  of  Data: 

Trade-off  Evaluation  Results  for  Manpower  Requirements  for 
Equipments 

303.2.11.5A1  DETERMIME  PURPOSE:  To  determine  the  optimum  methodology  to  be  used  in  the 

REPAIR  battlefield  environment  so  as  to  restore  the  System/Subsystem/Critical 
METHOD  TO  Component  to  a  state  where  it  can  continue  its  mission  with 
BE  USED  full/partial  capability  or  at  least  be  retrievable  to  a  maintenance 
facility  for  extensive  repairs. 

303.2.11.5A2  DETERMINE  PURPOSE:  To  determine  the  procedure  to  be  adopted  to  replace  the 

REPLACQINT  critical  component  in  the  battlefield.  The  possible  source  of  parts  for 
PROCEDURES  the  replacement  process  any  be  any  of  the  following: 

TO  BE  USED  Spares 

Cannibalizing 

Interchange 

Substitution 

Sharing 

Fabrication 

The  procedure  must  be  detailed  and  provide  the  operator  with  all 
instructions  to  affect  the  replacement. 
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Label  Descriptioa 


303.2.11.5A3 


303.2.11.5A4 


303.2.11.5A5 


303.2. 11.5A6 


303.2.11.6 


DETERMINE  PURPOSE:  To  deteraine  the  method  by  which  the  component  is  to  be 

MENDING  mended.  A  generic  list  of  possible  mending  methods  may  include  any  of 
METHOD  AND  the  following: 

PROCEDURE  Jury  Rigging 

TO  BE  USED  Brazing 

Soldering 
Gluing 

The  procedure  must  be  detailed  and  proride  the  maTimiina  assistance  to 
the  operator  in  undertaking  the  process. 

DETERMINE  PURPOSE:  To  describe  the  altematire  repair  procedure  that  may  be 

OTHER  REP  adopted  in  the  battlefield  enwironaent  for  the  component.  The  analyst 
METHOD  i  must  remember  that  the  resources  required  for  the  mending  process 
PROCEDURE  should  be  available  in  the  battlefield  environment. 

TO  BE  USED 

DETERMINE  PURPOSE:  To  determine  the  procedure  for  bypassing  the  component  in 

PROCEDURE  order  to  restore  System/Subsystea  operation.  The  process  must  also 
TO  BE  USED  determine  any  hazards  or  potential  damage  that  may  be  caused  as  a 
TO  BYPASS  result  of  the  bypass. 

COMPONENT 

» 

IDEtRUT  PURPOSE:  To  determine  the  resources  required  to  repair  the 

REQUIRED  component  by  the  suggested  method  in  the  battlefield  environment.  The 
RESOURCES  resonrce  requirements  listing  should  should  specify  the  source  of 
FOR  REPAIR  parts,  the  required  tools,  manpower  requirements,  time  etc. 

Source  of  Data: 

Trade-Off  Evaluation  Results  on  Manpower  Requirements 
Assessment 

DETERMINE  PURPOSE:  To  determine  the  operational  node  of  the 

OPERAIIONL  Eqnipnent/System/Snbsystem  after  r^air.  The  process  would  identify 
MODE  AFTER  whether  the  Eqnipnent/System/Subsystem/Component  is  fully  operational, 
REPAIR  partially  operational  or  fit  for  recovery.  The  analyst  should  also 

identify  any  limitations  imposed  on  the  operation  not  already  specified 
in  the  technical  documents. 

Source  of  Data: 

Required  Operational  Characteristics 
Functional  Requirements  Data 
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Label  Description 


ATT/DES/DAI 

SYS/SDBSYS/ 
CRn  a»!P 

DATA  ATTER 
DESIGN  CHANG 

This  Data  Flow  contains  infoioation  on  the  reconmended  design 
modification  and  the  nature  of  the  Improveaent  as  regards  resilience  to 
battlefield  environment  for  all  SYstems/Subsystoas/Critical  Coiponents. 

ATT/REP/DAT 

COMPONENT 

DATA  AFTER 
REPAIR 

The  data  contained  in  this  pertains  to  the  components  functionality 
and  limitations  after  repair. 

BAI/DM6/IMP 

RATTTiEFTETJ^ 

DAHAtZ  AND 
IMPACT  DATA 

This  contains  a  description  of  the  type  of  damage  the  system  could 
encounter  on  the  battlefield  and  the  damage  to  its  operational 
capability. 

COHP/BTFASS 

LIST  OF  COMP 
REQOIRED  TO 

BE  BYPASSED 

This  Data  Flow  contains  a  list  of  components  that  are  to  be  bypassed  in 
the  event  that  they  fail  under  operational  conditions  in  the 
battlefield. 

COMP/IHDIG/METH 

LIST  OF  a»ff 
REQUIRING 
OTHER  REPAIR 
METHODS 

This  is  a  list  of  critical  components  that  will  have  to  be  repaired 
using  indigenous  methods  in  the  event  that  they  are  damaged 
during  battlefield  aerations.  , 

COHP/MEMD 

LIST  or  COMP 
REQUIRED  TO 

BE  MENDED 

The  data  contained  here  is  a  list  of  critical  components  that  require 
mending  in  the  battlefield  enviroment  in  the  event  of  a  malfunction. 

COMF/BEP 

LIST  OF  COMP 
REQUIRED  TO 

BE  REPLACED 

The  data  contained  here  is  a  list  of  components  which  are  to  be 
replaced  in  the  event  of  a  malfunction  in  the  battlefield  environment. 

OMTRACT/REQ 

CONTRACT 

REQUIRQffiNTS 

ACRONYMS:  RFP  REQUEST  FOR  PROPOSAL 

SON  STATEMENT  OF  NDRK 

PURPOSE  OF  DATA:  PROVIDE  THE  ANALYST  WITH  THE  DETAILS  OF  THE  CONTRACT 
REQUIREMENTS  FOR  THE  SYSTSI  OR  THE  DESIGN  BEING 
EVALUATED. 

SOURCE  OF  DATA:  CONTRACT  FILE  PROCURING  AND  ENGINEERING  ACTIVniES 
(RFP.  A18>  SON) 

CRIT/COW/DAIA 

CRITICAL 

COMPONENTS 

DATA 

The  information  contained  here  pertains  to  the  criticality  of  the 
components  to  System/Subsystem  operation. 

CRIT/COMP/LIST 

CRHICAL 

COMPONENTS 

LIST 

This  Data  Flow  contains  a  listing  of  the  critical  components  and  parts 
that  are  to  be  analyzed  for  Battle  Damage  Assessment  and  Repair. 

DES/CHG/COMP/LST 

coMPONorrs 
REQUIRING 
DESIGN  CHANG 

This  Data  Flow  contains  a  listing  of  the  Systan/Subsystem  components 
that  are  weak  in  design  with  respect  to  survivability  and  battlefield 
damage  assessment  and  repair. 
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Din/ACT 


LOR/BSLIS 


MAHP1IR/DW 


REC/DES/CBG 


REL/DWA 


Ldoel  Description 


FUNCTIONAL  This  Data  Flow  contains  those  itais  identified  as  new  Systea/Equipoent 
REQUIBQIENTS  functional  reqoiments. 

DATA 


INITIATE  PURPOSE:  THE  REQUIRED  ACTIONS  OF  THOSE  (IF  MORE  THAN  ONE)  ACTIVITIES 
ACTION  NECESSARI  TO  ACTUATE  AN  ILS  ELQ4EHT  ASSESSMENT  FOR  A  SYSTQ4  AND/OR 

EQUIPMENT  HHICH  PROVIDES  THE  FORMAL  AOTHORIZMION  FOR  THE  PERFORMANCE  OF 
AN  ILS  EFFORT.  THESE  INITITMING  ACTIONS  ARE  NORMALLY  PERFORMED  BY  THE 
ILSMI  AND/OR  THE  PEKXSRAM  MANAGER. 

NHL  INCLUDE  DATA  IDENTIFYING  THE  NEED  FOR  ASSESSING  AN  ALTERNMIVE 
SYSTBf/EQUIPMENT  OR  FOR  IMPLEMENTWION  OF  A  SPECIFIC  ILS/LSA  TASK,  AS 
APPLICABLE.  THIS  HEED  HAY  BE  BASED  OH  AN  EVALUMIOH  OF  THE  EXISTING 
REQUIRQIENTS  ON  THE  BASELINE  SYSTEM/EQDIPMENT  OR  ON  THE  ILS/LSA  TASKS 
NEEDED  TO  FULLY  DOCUMENT  AH)/OR  EVALUATE  TEE  IMPACT  OF  ILS  OH  THE  NEW  OR 
EXISTING  SYSTEM/EQUIPMBR  OVER  ITS  LIFE  CYCLE. 

THESE  DATA  HAY: 

1.  EENTIFY  THE  SPECIFIC  HS/LSA  TASK  TO  BE  IMPIiMENTED 

2.  ESTABLISH  MISSION  PROFILE 

3.  EENTin  THE  RESOURCES  THM  EXIST  AND/OR  MUST  BE  DEVELOPED 

4.  ESTABLISH  PRIORITIES. 

SOURCE  OF  DATA:  PROOUM  MANAGER  OR  ILSMT 


LEVEL  OF  The  data  contained  here  pertains  to  the  Level  of  Repair  results  and 
REPAIR  includes: 

RESULTS  1.  Maintenance  task  levels  identification 

2.  Manhours  recpiired  per  task 

3.  Materiels  required  for  repair: 

a.  Technical  Oocuaentation 

b.  Support  Equipaent 

c.  Training 

d.  Labor 


MANPOWER  This  Data  Flow  contains  infozaation  on  aanpower  requireaents, 
REQUIRfMENTS  inspection  procedures  and  results,  and  other  associated  paraaeters 
DATA  related  to  the  potential  inspections  of  the  developaental  systea  and/or 

aquipaent. 


RECOMfDDED  The  data  flow  contains  inforaation  on  the  nature  of  the  deficiency 
DESIGN  and  the  required  design  aodification  to  the  Critical  Ccaponent  to 

MODIFICWION  reduce  vulnerability  to  battlefield  daaage  and  to  iaprove 
battlefield  repair  characteristics. 


RELIABILITY  PURPOSE  OF  DMA:  TO  PROVIDE  THE  ANALYST  WITH  APPROPRIATE  RELIABILITY 
DMA  DMA.  THE  DETERMINMION  OF  THE  POSSIBLE  AND  PROBABLE  FAILURE  MODES 

REQUIRES  AN  ANALYSIS  OF  RELIABILITY  DMA  ON  THE  ITEM  SELECTED  TO 
PERFORM  EACH  OF  THE  SYSTQl  INTERNAL  FUNCTIONS.  IT  IS  ALWAYS  DESIRABLE  TO 
USE  RELIABILITY  DMA  RESULTING  FROM  RELIABILITY  TESTS  ON  THE  SPECIFIC 
EQUIPMENT  TO  BE  USED,  THE  TESTS  PERFORMED  UNDER  THE  IDENTICAL  CONDITIONS 
OF  USE.  WHEN  SUCH  TESTS  ARE  NOT  AVAILABLE,  RELIABILITY  DATA  FROM 
MIL-HDBK-217  OR  FROl  OPERMIONAL  EXPERIENCE  AMJ  TESTS  PERFORMED  UNDER 
SIMILAR  USE  CONDniONS  ON  ITDiS  SIMILAR  TO  THOSE  IN  THE  SYSTIM  SHOULD  BE 
USIB. 
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REP/COMP 

COMPONETS 

REPAIRABLE 

IN  BATTLE 

This  Data  Flow  contains  a  listing  of  components  that  are  resilient  to 
battle  damage  and  are  capable  of  being  repaired  on  the  battlefield. 

REP/MBTHOO 

REPAIR 

METHODOLOGY 

This  Data  Flow  contains  information  on  the  type  of  repcir  method  to  be 
used  for  a  failed  the  component  under  battlefield  conditions .  It 
describes  the  procedures  to  be  adopted  and  the  limitations  involTed. 

RSRC/REQ 

RESOORCEB 
REQUIRED  FOR 
REPAIR 

The  data  contained  here  pertains  to  the  resources  required  to  undertake 
the  repair  in  terms  of  manpower,  tools,  time  etc.  This  data  is  required 
in  Subtask  402.2.4  to  assess  the  combat  resource  requirements. 

SEI/3Y3/EQPT/TO 

3ELECTED 

3Y3TIM/ 

EQOIPMEMT 

FOR  AMALY3I3 

The  data  consists  of  a  description  of  the  System/Bubsystem  design  that 
the  Program  Management  Office  has  requested  be  analyzed  under  task 
303.2.11. 

Bach  BystWSubsystem  selected  for  analysis/evaluation  as  part  of  an 
OTerall  effort  to  analyze  sereral  Equipment/System  concepts.  The 
analysis  results  lead  to  a  tradeoff  evaluation  or  another  relational 
comparison  to  select  a  Systei/Sabsystem  that  conforms  most  closely  to 
th.e  program  requirements. 

3Y3/0PER/CAPAB 

3Y3TEM/30B- 

SY3TEH 

OPERATIONAL 

CAPABILITY 

The  data  contained  here  describes  the  opwational  capability  of  the 
Bqalpment/3ystem/3ubsystem  after  the  repair  has  been  completed. 

TECH/DAT/DNG 

TECHNICAL 

DATA  AMD 
DRANINGS 

This  Data  Flow  pertains  to  the  latest  technical  details  as  indicated  in 
all  of  the  program  and  contract  requirements  documents.  A  complete  set 
of  current  drawings  for  the  System/Subsystei  is  also  included  in  this 
data  flow. 
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AAF 

ACQUIRING 
ACTIVITY  FILE 

CONTAINS  THOSE  RECORDS,  DOCUMENTS,  DECISION  PAPERS,  SCHEDULES  THAT  WERE 
PREPARED  AS  PARI  OF  THE  ACQUISITION  INITIATION,  JUSTIFICATION,  AND 

PLANNING  PRIOR  TO  THE  ASSIQWENT  OF  A  PROGRAM  MANAGER. 


THE  ITEMS  IN  THIS  DATA  STORE  INCLODE: 

A.  REQUIRED  OPERATIONAL  CHARACTERISTICS 

B.  0(0  PLAN 

C.  DESIRED  R&M  PARAMETERS 

D.  THREAT  ANALYSIS  DATA 

E.  READINESS  OBJECTIVES  DATA 

F.  FUNTIOHAL  REQUIRQIENTS  DATA 
6.  PROJECTED  SCHEDULE  DATA 

H.  LOGISTICS  RESOURCES  DATA 

I.  TOA 

J.  TOD 

K.  COST  (  OPERATIONAL  EFFECTIVENESS  ANALYSIS  (COEA)  DATA 

L.  PROJECTED  COST  DATA 

M.  JUSTIFICATION  OF  MAJOR  SYSTEM  NEW  START  (JMSNS)  DATA 

N.  DESIGN  SPECIFICATIONS 

CONTRACT/FILE  CONTRACT  FILE  PURPOSE:  THIS  IS  A  REPOSITORY  OF  ANY  CONTRACTUAL  DOCUMENTS  AFFECTING 

THE  PROJECT.  THIS  FILE  MAY  BE  CALLED  UPON  TO  VERIFY  WHAT  THE  CONTRACTOR 
HAS  BEEN  TASKED  TO  DO  AND  HOW  WELL  HE  HAS  DONE  IT. 

SOURCE  OF  DATA:  APPROVED  OR  UNAPPROVED  RFP'S,  IFB'S,  AMY  CHANGES, 
PROGRESS  REPORTS,  ETC. 

HIST/FILE  HISTORICAL  DATA  CONTAINS  DATA  PREVIOUSLY  ACQUIRED  ON  THE  ITEM  UNDER  INVESTIGATION  OR 

FILE  SOME  SIMILAR  SYSTEM  AND  MAY  ADDRESS  THE  FOLLOWING  AREAS  (TO  BE  TREATED 

SEPARATELY): 

1.  RELIABILITY  DATA 

2.  FAILURE  RATE  DATA 

3.  SPARES  AND  SPARE  FUNDING  DATA 

THE  AVAILABILITY,  ACCURACY,  AND  RELEVANCY  OF  EXPERIENCE  OF  HISTORICAL 
DATABASES  FR(M  SIMILAR  EXISTING  SYSTEMS  (OR  LOGISTICALY  EQUIVALENT 
SYSTEMS)  IS  CRUCIAL  FOR  ACC(MFLISEMENT  OF  THE  LSA  TASK  IN  QUESTION. 


HIST/INSF/EXP  HISTORICAL  A  Historical  File  of  iospection  experiences  for  like  Systais/Eqaipnent 
INSPECTN  EXPRNC  tiiat  can  be  used  as  a  basis  for  developoent  of  manpower  reqairements, 
inspection  procedures  and  results,  and  other  associated  parameters 
related  to  the  potential  inspections  of  the  developmental  system  and/or 
equipment. 
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Name 

Label 

Desciiption 

P/F 

POLICY  FILES 

CONTAINS  THOSE  MILITARY  PUBLICATIONS,  DECISION  PAPERS,  MISSIONS  i 

FUNCTIONS,  etc,  HHICS  ARE  NEEDED  TO  ESTABLISH  THE  LOGISTICAL  SUPPORT  AND 
REVIEN  REQUIREMENTS  OF  THE  ITE24/EQOIPMENT  DEVELOPMENT  PROGRAM. 

THIS  DATA  STORE  INCLUDES; 

1.  AR  12-16,  "MUTUAL  LOGISTICS  SUPPORT  BETWEEN  THE  U.S.  AND  OTHER 

NORTH  ATLANTIC  TREATY  ORGANIZATION  FORCES" 

la.  AR  70-1,  "SYSTEMS  ACQUISITION  POLICY  AND  PROCEDURES" 

lb.  AR  70-2,  "RESEARCH,  DEVELOPMENT,  i  ACQUISITION  MATERIEL  STATUS 

RECORDING" 

lc.  AR  70-10,  "RSD  -  TEST  5  EVALUATION  DURING  DEVELOPMENT  AND 

ACQUISITION  OF  MATERIEL" 

ld.  "AR  570-9,  "MANPOWER  AND  EQUIPMENT  CONTROL  -  HOST  NATION  SUPPORT" 

2.  AR  700-9,  "POLICIES  OF  THE  ARMY  LOGISTIC  SYSTEM" 

3.  AR  700-82,  "JOINT  REGULATIOI  GOVERNING  THE  USE  AND  APPLICATION  OF 

UNIFORM  SOURCE  MAINTENANCE  AND  RECOVERABILITY  CODES" 

4.  AR  700-127,  "INTEGRATED  LOGISTICS  SDPPPORT" 

5.  AR  725-50,  "REQUISITIONING,  RECEIPT  AND  ISSUE  SYSTOT 

6.  AR  750-1,  "MAINTENANCE  OF  SUPPLIES  S  EQUIPMENT  -  ARMY  MATERIEL 

MAINTENANCE  CONCEPTS  i  POLICIES" 

7.  AMC-R-700-27,  "LEVEL  OF  REPAIR  ANALYSIS  (LORA)  PROGRAM" 

8.  AMC-R-750-10,  "DEPOT  MAINTENANCE  INTERSERVICE" 

9.  DA  PAH  700-4 

10.  DA  PAM  700-28,  "INTEGRATED  LOGISTIC  SUPPORT  PROGRAM  ASSESSMENT 

ISSUES  AMD  CRITEm* 

11.  DA  PAM  700-50,  "INTESIATED  LOGISTIC  SUPPORT  -  DEVELOPMENTAL 

SUPPORTABILITY  TEST  AMD  EVALUATION  GUIDE" 

12.  DA  PAM  700-55,  "INSTRUCTIONS  FOR  PREPARING  THE  INTEGRATED 

LOGISTIC  SUPPORT  PLAN” 

12a.  DA  PAM  738-750,  "THE  ARMY  HAdTENAHCE  MANAGEMENT  SYSTEMS  (TAtflS)" 

13.  DA  PAM  750-21,  "LOGISTIC  SUPPORT  MODELLING" 

14.  AMC  PAM  700-4,  "LOGISTICS  SUPPORT  ANALYSIS  TECHNIQUES  GUDE 

(WITH  PAIMAN)" 

14a.  AMC  PAM  700-11,  "LOGISTICS  SUPPORT  ANALYSIS  REVIEW  TEAM  GUIDE" 

15.  AMC  PAM  750-2,  "MAINTENANCE  OF  SUPPLIES  AND  EQUIPMENT  GUIDE  TO 

RELIABILITY  CENTERED  MAINTENANCE" 

16.  MIL-STD-152,  "TECH  REVIEW  GUIDELINES" 

17.  MIL-STD-210A,  "CLIMATIC  EHREMES  FOR  MILITARY  EQUIPMENT" 

18.  MIL-STD-470,  -471,  "MAINTAINABILITY  STANDARDS" 

19.  MIL-STD-756,  "RELIABILITY  MODELLING  i  PREDICTIONS" 

20.  MIL-STD-780,  "MAINTENANCE  ENGINEERING  ANALYSIS  CONTROL  NUMBER 

(MEACNS)  FOR  AERONAUTICAL  EQUIPMENT,  UNIFORM 
NUMBERING  SYSTEM 

21.  MIL-STD-781,  "RELIABILITY  DESI®  QUALIFICATION  AND  PRODUCTION 

ACCEPTANCE  TESTS:  EXPONENTIAL  DISTRIBUTION 

22.  MIL-STD-785B,  "RELIABILITY  PROGRAM  FOR  SYSTEMS  AND  EQUIPMENT 

DEVELOPMENT  &  PRODUCTION" 

23.  MIL-STD-810,  "ENVIRONMENTAL  TEST  METHODS  &  ENGINEERING  GUIDELINES" 

24.  MIL-STD-881,  "WORK  BREAKDOWN  STRUCTURES  FOR  DEFENSE  MATERIEL  ITEMS 

25.  MIL-STD-882,  "SYSTEM  SAFETY  PROGRAM  REQUIRMENTS" 

26.  MIL-STD-965,  "PARIS  CONTROL  PROGRAM" 

27.  MIL-STD-1369A,  "INTEGRATED  LOGISTIC  SUPPORT  PROGRAM  REQUIREMENTS" 

28.  MI1-STD-1388-1A,  "LOGISTICS  SUPPORT  ANALYSIS" 

29.  MIL-S2D-1J88-2A,  "LOGISTICS  SUPPORT  ANALYSIS  RECORD" 

30.  MIL-STD-1629,  "PROCEDURES  FOR  PERFORMING  A  FAILURE  MODE,  EFFECTS 
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Name 


Label  Description 


i  CRITICALITY  ANALYSIS" 

31.  MIL-HDBK-472,  "MAINTAINABILITY  PREDICTION" 

32.  MIL-M-24100B,  "FDNCTIOHAIY  ORIENTED  MAINTENANCE  MANDALS  (FOMM) 

FOR  EQOIPMENT  &  SYSTEMS" 

PH/DF  PROGRAM  MANAGER  Contains  those  files  and  data  which  are  noroally  developed  by 

DATA  FILE  and/or  retained  by  the  Program  Manager  for  proper  management  of 
the  Development  Program.  These  files  include: 

1.  Engineering  Drawings 

2.  Engineering  Characteristics 
■  3.  DT/OT  Rasolts 

4.  Concept  Formulation  Package  (CFP) 

5.  Design  Conc^t  Paper  (DCP) 

6.  Type  Technical  Reviews  Required 

7.  Milestone  Schedules 

8.  Funding  Profiles 

9.  Required  Operational  Capabilities  (ROC) 

10.  Item/Equipment  Specifications 

11.  Item/Equipment  Missions  and  Functions 

12.  Equipment,  Manpower,  and  Technical  risk  assessments  (From 
LSA  Task  301.2.3) 

13.  Tradeoff  Determination  Analysis  (TOD) 

1;.  Tradeoff  Analysis  (TOA) 

15.  Beast  Technical  Approach  Analysis  (BTA) 

16.  Cost  and  Operational-Effectiveness  Analysis  (COEA) 

17.  Hardware  S^ifications 

18.  RAM  Requirements 
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Name 

Label 

Description 

PM/ILSHI 

m/ILSKr 

The  Prograa  Manager  or  those  activities. 

agencies  or  authorities  that 

are  raapoasUble  for  the  initiation  of  the  reqairenent  for  an  ILS  elesent 
asseassent  during  a  deTalopaent  prograa  for  a  systan  and/or  eqaipient  in 
accordance  with  AR  700-127.  The  hey  action  (output)  required  of  this 
external  entity  is  the  directive,  authority,  or  other  documentation  that 
initiates  the  reqnireient  for  the  application  of  this  ILS  assessment  to 
a  specific  systei/equipment  development  program  at  a  specified  point  in 
it's  life  cycle  in  accordance  with  AR  700-127. 

3IS/DGI/DES  37STQ1  This  entity  refers  to  the  designer  of  the  system  being  investigated. 

DETAIL  The  entity  controls  the  Equipment/Systea/Subsystem  technical 

DESIGNER  specifications  and  drawings. 
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ANNEX  C 
SUBTASK  303.2.11 

SURVIVABILITY  AND  BATTLE  DAMAGE  REPAIR  CHARACTERISTICS 


PROCESS  303.2.11.1  -  SELECT  SYSTEM/ SUBSYSTEM 
PURPOSE 

To  select  the  system/ subsystem  to  be  analyzed  in  this 
iteration  of  the  LSA  Sxibtaak.  The  system/sxabsystem  so  selected 
must  conform  to  the  Work  Breakdown  Structure  (WBS)  set  forth  in 
MIL-STD-881. 

PROCEDURES 

1.  Obtain  the  Work  Breakdown  Structure  (WBS),  technical 
drawings  auid  specifications  for  the  equipment  to  be 
analyzed.  If  no  WBS  is  available  for  the  equipment, 
the  system/ subsystem  may  be  selected  from  the 
following  generic,  though  not  all  inclusive,  list: 

• 

a.  Power  Plant  Systems 

b.  Fuel  Systems 

c .  Electrical  Systems 

d.  Hydraulic/Pneumatic  Systems 

e .  Transmission  Systems 

f .  Drive  Systems 

g.  Track/Suspension 

h.  Aircraft  Airframe  Systems 

i .  Armament  Systems 

j .  Fire  Control  Systems 

k.  Communication  and  Control  Systems 

l.  Electronic  Systems 

m.  Humem  Accommodations 

2 .  The  analyst  with  the  cooperation  of  the  systems 
engineer,  must  develop  a  list  of  the  systems/ 
subsystems  within  the  design  that  should  be  analyzed. 
The  selection  should  include  the  systems /subsystems 
that  have  high  failure  rates  as  indicated  in  the  FMECA 
data.  Selection  can  also  be  based  on  the  projected 
extent  of  battle  deunage,  considering  the  items 
vulneraUaility  and  the  impact  its  loss  would  have  on 
the  operation  of  the  system. 

Should  a  system/subsystem  for  the  equipment  not  be 
availadale  in  the  generic  list  it  may  be  added  to  the 
database  by  selecting  <NEW>  option. 
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PROCESS  303.2.11.2  -  EVALUATE  COMPONENTS  FOR  THEIR  CRITICALITY 


To  evaluate  the  components  of  the  system/siibsystem  for 
their  criticality  in  performing  the  fxmctional  requirements . 

PROCESS  303.2. 11. 2A1  -  Assess  Battle  Damage  Resilience 

Characteristics 

PURPOSE 

To  review  the  survivability  auid  vulneraibility 
characteristics  of  the  system/ subsystem  and  determine  the  extent 
to  which  its  components  are  resilient  to  battlefield  damage. 

PROCEDURES 

1 .  Obtain  the  following  documents  that  refer  to  the 
implementation  of  BOAR: 

a.  AR  70-1  Systems  Acquisition  Policy  and  Procedure 

b.  AR  750-1  Materiel  Maintenemce  Concepts  aind 
Policies 

c.  AR  700-127  Integrated  Logistics  Support  (ILS) 

d.  MIL-STD-1388-1A/2A  Logistics  Support  Analysis 

e.  MIL-M-63003  Preparation  of  BDAR  TM' s 

f .  AMCCOM  Regulation  750-5  Battle  Damage  Assessment 
and  Repair 

g.  Engineering  Drawings  and  Technical  Specifications 
of  the  equipment /system/ subsystem  from  the 
Program  Memagers  Data  File 

h.  Design  Specifications  from  the  Acquiring  Activity 

File 

Note:  AMSAA  defines  Survivability  as: 

That  characteristic  of  personnel  and  materiel  which 
enables  them  to  withstand  (or  avoid)  adverse  military 
action  or  the  effects  of  natural  phenomena  which 
ordinarily  or  otherwise  would  result  in  the  loss  of 
cap203ility  to  continue  effective  performeuice  of  the 
prescribed  mission. 

2.  The  analyst  must  assess  each  system/subsystem' s 
surviveQjility  characteristics.  The  system/subsystem 
should  be 

(a)  Be  difficult  to  detect  and  acquire 

(b)  If  acquired,  be  difficult  to  hit 

(c)  If  hit,  be  difficult  to  damage 

(d)  If  damaged  be  easy  to  repair 
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Note:  In  the  case  of  2d  aibove  it  does  not  necessarily  imply 

that  the  system/sxibsystem  has  to  be  returned  to  full 
functional  capability  after  the  repair.  The  emphasis 
here  should  be  on  expedient  repair  with  the  avail2Lble 
resources  to  restore  some  functional  capability 
essential  to  the  battlefield  commauider. 


PROCESS  303.2. 11. 2A2  -  Identify  Critical  Components 
PURPOSE 

To  determine  the  extent  to  which  a  component  is  critical  to 
the  operation  of  the  equipment / system/ s\absy stem.  In  doing  so 
the  emalyst  must  take  into  account  the  survivability 
characteristics  of  the  component  auid  the  functional  requirements 
of  the  system/ subsystem. 

PROCEDURES 

1.  Obtain  the  following  data  from  the  Program  Mauiager's 
office: 

a.  Reliability  Data 

b.  Failure  Rate  Data 

c.  Required  Operational  Characteristics 
O&O  Plan 

d.  Functional  Requirements  Data 

2.  Assess  each  component  ^md  estedslish  whether  the 

component  is  critical  to  the  perfozrmance  of  the 
Functional /Operational  requirements  of  the 

System/Subsystem. 

3 .  In  assessing  the  criticality  of  the  components  its 
reliability  and  failure  rate  data  must  be  taken  into 
account . 

4 .  Although,  cause  is  not  a  factor  for  BDAR,  it  is 

pertinent  to  consider  all  possible  causes  that  could 
render  the  component  unserviceed^le  or  cause  damage  to 
it.  The  possible  causes  are: 

a.  Normal  Wear  and  Tear 

b.  Careless  or  Improper  Use 

c .  Terrain 

d.  Improper  Maintenance  Practices 

e.  Enemy  Action 

5.  The  analyst  must  identify  which  of  the  components  in 
the  Equipment  have  to  be  repairaJDle  on  the 
battlefield.  Only  those  components  that  are  critical 
to  Mission  Performance  or  to  Self  Retrieval  are  to  be 
considered  as  CRITICAL  (have  to  be  repairable) 
components . 
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PROCESS  303.2.11.2A3  -  Determine  the  Function  Lost  Due  to  the 

Damage 


PURPOSE 

This  process  determines  the  functions  that  would  be  lost 
due  to  the  various  types  of  damage  that  could  occur  to  the 
system/ STobsy stem/ component  when  operating  in  the  battlefield 
environment.  This  process  further  exemplifies  the  criticality 
of  the  component  in  the  performance  of  its  operational 
functions . 

PROCEDURES 

1 .  Obtain  the  following  data  from  the  Progreun  Magiager'  s 
Office; 

a.  Required  Operational  Characteristics 

b.  Functional  Requirements  Data 

c.  O&O  Plan 

2.  For  each  component^  identify  the  possible  damages  that 
could  occur. 

3.  For  each  possible  damage  that  could  occur  identify  and 
list  the  Operational  and/or  Functional  requirement 
that  the  Con^onent  will  be  unable  to  perform. 


PROCESS  303.2.11.3  -  CONDUCT  DAMACT  ASSESSMENT 
PURPOSE 

This  process  assesses  all  possible  types  of  damage  that 
could  be  caused  to  the  critical  components .  The  dcimage 
assessment  must  segregate  systems/subsystems /critical  components 
that  are  poorly  designed  for  surviveUbility  and/or  battlefield 
repair  from  those  that  are  resilient  to  battle  damage  and 
capable  of  being  repaired  on  the  battlefield. 

PROCEDURES 

1.  Obtain  the  following  data: 

a.  Technical  Drawings  and  Specifications 

b.  Level  of  Repair  results 

2.  The  analyst  must  assess  the  various  critical 
components  and  identify  whether  the  damage  is 
repaireU^le  on  the  battlefield  or  whether  a  design 
change  is  required  to  make  the  critical  component  more 
battle  resilient . 
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3.  The  analyst  must  determine  whether  the  design  of  the 
critical  component  will  allow  a  deunage  assessment  to 
be  made  on  the  battlefield.  To  do  so  the  amalyst  must 
study  the  Technical  Drawings  and  if  available  take  a 
look  at  the  prototype  of  the  system/ subsystem  amd 
identify  whether  the  part  is  accessible  in  the 
battlefield. 


4 .  There  are  four  ways  in  which  to  conduct  a  damage 
assessment.  The  system/s\absystem/critical  component 
must  allow  either  one  or  more  of  the  following: 

a.  Automatic  Assessment 

b .  Visual  Inspection 

c .  Testing 

d.  Process  of  Elimination 


5.  The  auialyst  would  have  to  make  a  trade-off  between 
Assessability  and  Survivability  of  all  critical 
components .  The  critical  components  as  deficient  in 
these  aspects  of  design  should  be  identified  as 
requiring  design  modifications. 

» 

Note:  For  survivadbility  the  aim  is  to  protect  or  cover,  amd 

thereby  hide  a  critical  part;  whereas  accessibility 
involves  exposing  a  component  to  potential  damage. 

6.  For  the  remaining  critical  components,  the  analyst 
must  determine  whether  they  are  designed  for  expedient 
repairs  in  the  battlefield  environment. 


7 .  Other  factors  to  consider  while  assessing  a  critical 
component  for  Battle  Daunage  Assessment  amd  Repair  are 
to  identify  whether  the  component  design: 

-  has  built  in  rediandamcy 

-  is  modular 

-  the  system/subsystem  can  utilize  stamdard  parts. 

8 .  The  Analyst  must  then  list  the  components  in  two 

categories : 

a.  Requiring  a  Design  Modification 

b.  CapaQjle  of  being  repaired  in  the  battlefield 
environment 


PROCESS  303.2.11.4  -  RECOMMEND  DESIGN  CHANGES 
PURPOSE 

To  recommend  design  chamges  that  must  be  implemented  to 
make  the  system/ subsystem/ component  resilient  to  battle  daunage 
and  make  it  repairadjle  on  the  battlefield. 
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PROCSDOBES 


1 .  The  analyst  in  consultation  with  the  maintenance 
engineers  must  recommend  design  changes  which  improve 
the  survivability,  battle  resilience  and  the 
repairability  of  the  critical  component  identified  as 
requiring  such  design  modifications  in  process 
303.2.11.3. 


2.  In  assessing  the  design  deficiency  of  the 
system/ STobsy stem/ component  the  analyst  must  consider 
whether  the  component  design  incorporates  one  or  more 
of  the  following  factors : 

a.  Easy  accessibility  of  parts 

b.  Automatic  assessment  capability 

c.  Designed  for  testing 

d.  Designed  for  elimination/bypassing 

e .  Incorporates  Built-in-redundancy 

f.  Contributes  to  survivability 

g.  Permits  repair  in  the  battlefield  environment 


3 .  The  analyst  must  also  specify  how  the  design 
modification  will  improve  the  survivability,  battle 
resilience  and  repairability  characteristics  of  the 
critical  component. 


PROCESS  303.2.11.5  -  RBCOMMSMD  REPAIR  METHODOLOGY 
PURPOSE 

This  process  evaluates  the  availcQsle  repair  alternatives  to 
restore  as  much  of  the  system/subsystem/critical  Component's 
operational  capabilities  as  possible.  Having  evaluated  the 
various  alternatives  the  analyst  is  to  recommend  the  optimum 
method  of  repair.  The  analyst  must  also  state  the  resources 
required  to  undertake  the  repair  in  terms  of  required  tools, 
manpower,  time  etc. 


PROCESS  303.2.11.5A1  -  Determine  Repair  Method  to  be  Used 
PURPOSE 

To  determine  the  optimum  methodology  to  be  used  in  the 
battlefield  environment  so  as  to  restore  the  system/subsystem/ 
critical  component  to  a  state  where  it  ceui  continue  its  mission 
with  full/partial  capability  or  at  least  be  retrievable  to  a 
maintenance  facility  for  extensive  repairs. 
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PROCEDUPES 


1 .  The  analyst,  must  assess  the  severity  of  the  damage  as 
regards  mission  accomplishment  (with  full  or  partial 
capeibility)  .  Having  done  so  he/ she  is  to  recommend  a 
method  of  repair  to  make  the  System/ Subsystem/ Critical 
Component  cap2d3le  of  continuing  the  mission  or 
returning  to  the  maintenance  area. 

2 .  Assess  the  nature  of  repairs  required  to  restore  the 
lost  function,  either  fully  or  partially  as  soon  as 
possible. 

3 .  Identify  the  methodology  to  be  adopted  in  affecting 
the  repair  in  the  most  efficient  mauiner.  The  method 
used  should  fall  into  one  of  four  broad  categories : 

a.  Replace  a  damaged  component  or  siobsystem 

b.  Mend  the  damaged  component  or  subsystem 

c.  Bypass  the  damaged  component  or  subsystem 

d.  Use  other  creative  or  resourceful  means  to 
provide  the  needed  function  to  the  system, 
subsystem,  or  Critical  Component 

In  determining  the  repair  method  the  analyst  must 
consider  the  availability  of  the  required  resources  in 
the  battlefield  environment. 


PROCESS  303.2.11.5A2  -  Determine  Replacement  Procedure  to  be 

Used 


PURPOSE 

To  determine  the  procedure  to  be  adopted  to  replace  the 
critical  component  in  the  battlefield.  The  possible  source  of 
parts  for  the  replacement  process  may  be  any  of  the  following: 

a .  Spares 

b.  Cauinibalizing 

c .  Interchange 

d.  Sxibstitution 

e .  Sharing 

f.  FeJsrication 

The  procedure  must  be  detailed  and  provide  the  operator 
with  all  instructions  to  affect  the  replacement. 

PROCEDURES 

1.  Determine  the  source  of  the  replacement  part  from  one 
of  the  six  methods  mentioned  adaove . 
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2 .  Replacement  of  a  component  will  most  likely  restore 
the  full  function  of  the  system/subsystem/critical 
component .  In  the  event  that  the  replacement  is 
carried  out  by  cannibalizing  from  within  the 
system/subsystem  it  is  possible  that  the  portion  of 
the  system  from  which  the  component  was  cannibalized 
might  have  degraded  capadbility/performance . 

3.  Identify  the  time  required  to  diagnose,  remove, 
reinstall  aind  test  the  components.  Also  assess  the 
manpower  requirements  and  the  tools  required  to 
conduct  the  process . 

4.  When  using  substitute  parts  that  do  not  fit  exactly, 
specify  the  adaptation  and  modifications  required  in 
the  replacement  process. 

5 .  Develop  a  step-by-step  procedure  to  be  adopted  when 
replacing  the  component,  if  such  a  procedure  does  not 
already  exist  in  the  maintenance  manuals  for  the 
system/ svibsy  stem. 


PROCSSS  303.2.11.5A3  -  Determine  The  Mending  Method  and 

Procedure  to  be  Used 


PURPOSE 

To  determine  the  method  by  which  the  component  is  to  be 
mended.  A  generic  list  of  possible  mending  methods  may  include 
any  of  the  following: 

Jury  Rigging  -  patching  an  existing  part  by  gluing, 
tying  or  sxibstituting  almost  anything  that  will  allow 
the  function  to  continue. 

Brazing/Soldering  -  Uniting  metal  pieces  by  intensely 
heating  the  parts  to  be  joined. 

The  procedure  must  be  detailed  and  provide  the  maximum 
assistance  to  the  operator  in  undertaking  the  process . 

PROCBDURBS 

1 .  Assess  the  nature  of  the  deunage  and  whether  the  daimage 
can  be  repaired  by  mending. 

2 .  Identify  the  method  that  is  to  be  employed  for  the 
mending  process  and  assess  the  manpower  requirements 
and  the  tools  recpjired  to  conduct  the  repair. 

3.  Determine  the  time  required  to  diagnose,  remove,  mend, 
refit  and  test  the  component. 
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4. 


Specify  the  adaptation  and  modifications  required  in 
the  mending  process . 


5 .  Develop  a  step-by-step  procedure  to  be  adopted  when 
mending  the  component,  if  such  a  procedure  does  not 
already  exist  in  the  maintenance  mauiuals  for  the 
system/ subsystem/ component . 


PROCBSS  303.2.11.5A4  -  Determine  The  Other  Repair  Method  and 

Procedure  to  be  Used 

PURPOSS 

To  describe  the  alternative  repair  procedure  that  may  be 
adopted  in  the  battlefield  environment  for  the  component.  The 
amalyst  must  remember  that  the  resources  required  for  the 
mending  process  should  be  available  in  the  battlefield 
environment . 

PROCEDURES 

1 .  Assess  the  natur--  of  the  daunage  auid  identify  any 
alternative  repair  procedure  that  may  be  applied  to 
restore  the  functionality  of  the  component . 

2 .  Having  identified  an  improvised  procedure  that  may  be 
adopted  specify  the  parts  or  other  indigenous  items 
that  may  be  required  to  carry  out  the  repair  process . 

3 .  Assess  the  manpower,  time  amd  tools  required  to 
diagnose,  remove,  repair,  test  and  replace  the 
component  in  the  battlefield  environment.  In  this 
regard  the  amalyst  may  consider  that  in  the  battle¬ 
field  environment  the  repair  crew  may  not  adhere  to 
standard  safety  procedures  auid  adopt  shortcuts  in  the 
repair  process. 

4 .  Develop  a  step-by-step  procedure  to  be  adopted  when 
repairing  the  component  in  such  an  improvised  .uanner 
if  such  a  procedure  does  not  already  exist  in  the 
maintenauice  manuals  for  the  system/ subsystem. 

5 .  The  analyst  should  specify  any  inherent  hazards  to 
personnel  or  additional  daimage  to  the  system/ 
s\absy stem/ component  that  might  occur  as  a  result  of 
such  an  indigenous  method  being  adopted.  The  analyst 
must  ensure  that  the  hazards  so  specified  fall  within 
the  bounds  of  the  philosophy  of  battle  resilience  and 
survivability . 
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PROCESS  303.2.11.5A5  -  Determine  the  Procedure  to  be  Used  to 

Bypass  the  Component 


PURPOSE 

To  determine  the  procedure  for  bypassing  the  component  in 
order  to  restore  the  system/ subsystem  operation.  The  process 
must  also  determine  euiy  hazards  or  potential  damage  that  may  be 
caused  as  a  result  of  the  bypass. 

PROCEDURES 

1 .  Assess  the  nature  of  the  daimage  aund  assess  the  pros 
auid  cons  of  bypassing  the  component  in  order  to 
restore  the  system/ sxibsystem' s  functionality. 

2.  Identify  any  expedient  materiels/parts  that  might  be 
required  to  affect  the  bypass . 

3 .  Assess  the  manpower,  time  and  tools  required  to 
accomplish  and  test  the  bypass.  In  this  regard  the 
ainalyst  may  consider  that  in  the  battlefield 
environment  the  repair  crew  may  not  adhere  to  standard 
safety  procedures  and  adopt  shortcuts  in  the  repair 
process . 

4.  Develop  a  step-by-step  procedure  to  be  adopted  when 
bypassing  the  component  if  such  a  procedure  does  not 
already  exist  in  the  mainteneuice  manuals  for  the 
system/ svibsy  stem . 

5 .  The  analyst  should  specify  any  inherent  hazards  to 
personnel  or  additional  daunage  to  the  system/ 
subsystem/component  that  might  occur  as  a  result  of 
the  bypass.  The  analyst  must  ensure  that  the  hazards 
so  specified  fall  within  the  bounds  of  the  philosophy 
of  battle  resilience  and  survivability. 


PROCESS  303.2.11.5A6  -  Identify  the  Required  Resources  for  the 

Repair 

PURPOSE 

To  determine  the  resources  required  to  repair  the  component 
by  the  suggested  method  in  the  battlefield  environment.  The 
resource  requirements  listing  should  specify  the  source  of  the 
parts,  the  required  tools,  manpower  requirements,  time  etc. 

PROCEDUR}  3 

1.  Depending  on  the  methodology  to  be  adopted  for  the 
repair,  the  analyst  must  identify  all  the  possible 
components  or  materiels  required  to  carry  out  the 
repair  process . 
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2 .  For  each  component  or  materiel  so  identified,  specify 
where  the  item  is  to  be  obtained  (from  kits,  by 
STobstitution  from  standard  or  non  standard 
replacement,  by  improvising  from  other  items  available 
in  the  battlefield  etc . ) . 

3 .  Assess  the  requirements  of  tools  for  the  process  and 
discuss  their  availability  in  the  battlefield. 

4 .  Assess  the  m2mpower  requirements  for  the  process .  The 
auialyst  must  bear  in  mind  that  it  is  not  always 
necessary  to  have  specialized/ideally  qualified 
personnel  to  do  the  job  in  the  battlefield 
environment . 

5.  Assess  the  time  requirements  to  complete  the  repair 
process  by  the  suggested  method. 

6 .  Identify  any  other  special  requirements  that  might  be 
required  to  efficiently  conduct  the  repair  process . 


PROCBSS  303 .2.11.6  -  DSTBBMIKZ  THE  OPEXUWTIOMAl.  MODE  AFTER  REPAIR 
PURPOSE 

To  determine  the  Operational  mode  of  the  equipment /system/ 
subsystem  after  repair.  This  process  identifies  whether  the 
equipment/system/ subsystem/component  is  fully  operational, 
partially  operational  or  fit  for  recovery.  The  analyst  should 
also  identify  any  limitations  imposed  on  the  operation  not 
already  specified  in  the  technical  documents. 

PROCEDURES 

1.  Assess  the  capability  of  the  System/Sxabsystem  after 
the  repair  has  been  completed.  Classify  the 
equipment /system/ subsystem' s  operational  mode  in  one 
of  the  following  ways : 

a .  Fully  Capable 

b .  Partially  Capable 

c.  Self-Recovery  Capable 

2 .  Describe  any  additional  precautions  or  limitations 
imposed  on  the  operation  of  the  equipment /system/ 
sxibsystem  after  repair.  This  description  must  also 
include  auiy  additional  hazards  to  personnel  or 
materiel . 
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ANNEX  D 

LSA  SUBTASK  303.2.11 
VERT  APPLICATION  METHODOLOGY 


VERT  APPUCATION  METHODOLOGY 


BACKGROUND: 


Venture  Evaluation  auid  Review  Technique  (VERT)  was 
developed  as  a  network  analysis  technique  to  facilitate 
meuiagement  decision  making.  It  allows  a  systematic  planning  and 
control  of  progrsuas  and  enables  managers  to  find  solutions  to 
real  life  meunagerial  problems. 

The  terms  of  the  APJ  contract  require  the  provision  of 
batch  files  for  each  of  the  VERT  networks  associated  with  the 
various  Data  Flow  Diagr2Lms  in  the  APJ  966  projects. 

APJ  has  been  successful  in  adopting  a  method  for  the 
creation  of  these  networks  using  the  existing  EXCELERATOR 
software  package  emd  establishing  a  nauaing  convention  compatible 
with  that  used  in  the  Data  Flow  Diagreuns .  To  do  this  APJ  has 
made  use  of  the  PC  model  of  VERT.  A  Structured  Analysis  project 
was  used  for  this  purpose.  The  prototype  VERT  network  structure 
was  made  for  one  top  level  2uid  one  lower  level  data  flow 
diagreim. 

The  PC  model  of  VERT  has  certain  limitations  built  into  it. 
To  overcome  some  of  these  limitations^  certain  conventions  were 
used  to  create  the  input  files.  To  maintain  full  generality  a 
set  of  "dummy”  default  values  were  established.  The  model 
allows  the  user  to  alter  the  default  values  of  time^  cost^  emd 
performance  to  satisfy  their  specific  requirements. 

METHODOLOGY: 


The  basic  symbols  used  to  structure  the  network  are: 

(i)  SQUARES  -  to  indicate  NODES.  These  are  decision 
points  in  the  project,  or  points  beyond  which  the 
project  cannot  proceed  iinless  certain  criteria  are 
met.  There  are  two  type  of  nodes,  one  which  supports 
input  operations  and,  the  second  type  which  supports 
output  operations . 

(ii)  LIMBS  -  to  indicate  ARCS  which  are  activities  that 

have  time,  cost,  and  performance  criteria  associated 
with  them. 

In  practice,  however,  both  the  arcs  and  nodes  are  similar, 
in  that  both  have  time,  cost,  and  performance  criteria 
associated  with  them.  The  arcs  have  a  primary  and  a  cumulative 
set  of  time,  cost,  and  performance  criteria  whereas  the  nodes 
have  only  a  single  cumulative  set . 

(iii)  NAMING  CONVENTIONS  -  Efforts  have  been  made  to  keep 

the  natming  convention  as  compatible  as  possible  to  the 
Data  Flow  Diagrams.  The  naming  convention  used  is 
displayed  below. 


NODES  -  All  nodes  are  prefixed  with  the  letter  N. 
The  individual  Nodes  are  identified  by  a  number 
auad  a  letter.  The  number  refers  to  the  number  of 
the  node  within  the  diagraun  and  the  letter  refers 
to  the  diagram  number  in  the  project.  In  the 
event  that  a  node  has  been  referenced  in  an 
earlier  diagram  they  also  carry  the  number  of  the 
node  in  the  earlier  diagram  as  a  prefix  to  the 
individual  node  ntunber. 

N2.4A 

N  -  All  nodes  are  prefixed  with  the  letter  N 
2  -  Gives  the  number  of  the  node  it  relates  to  in 
a  higher  level  diagram  or  an  earlier  data 
flow  diagram  within  the  project.  In  this 
case  it  refers  to  node  N2  of  the  top  level 
diagr2ua. 

4  -  Gives  the  nximber  of  the  node  it  relates  to  in 

a  higher  level  diagram  or  an  earlier  data 
flow  diagrauR  within  the  project.  In  this 
case  it  refers  to  node  N2  of  the  top  level 
diagram. 

A  -  The  nodes  in  each  subsequent  explosion  are 
allotted  an  alphabetical  suffix  indication 
the  number  of  the  explosion  diagram  in  the 
pairticular  project.  In  this  case  it  is  the 
first  lower  level  diagram  within  the  project. 

ARCS  -*  All  arcs  are  prefixed  with  either  the  letter 
C  or  E.  The  individual  Arcs  are  identified  by  two 
numbers .  The  first  number  refers  to  the  number  of 
the  arc  within  the  diagreun  and  the  second  number 
refers  to  the  number  of  the  diagram  within  the 
project.  In  the  event  that  aui  arc  has  been 
referenced  in  an  earlier  diagreun  they  also  carry 
the  number  of  the  arc  in  the  earlier  diagreun  as  a 
prefix  to  the  individual  arc  number.  The  arcs 
which  are  identified  by  the  letter  E  have  direct 
reference  to  a  process  in  the  corresponding  data 
flow  diagr2un  and  as  such  are  named  the  same  as  the 
process  itself. 

C3 . 3 . 8 . 4  E12 . 1A2 

C  -  All  arcs  are  prefixed  with  the  letter  C.  In 
some  cases,  however,  arcs  carry  a  prefix  of 
E.  These  particular  arcs  correspond  to  a 
process  within  the  data  flow  diagram  and  are 
thus  named  the  same  as  the  process  itself. 
3.3-  Gives  the  number  of  the  arc  it  relates  to  in 
a  higher  level  diagram  or  an  earlier  data 
flow  diagram  within  the  project.  In  this 
case  it  refers  to  arc  number  3  in  lower  level 
diagram  #3  within  the  project . 
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8.4-  Indicates  that  this  particular  arc  is  the  #8 
arc  in  the  #4  lower  level  diagram  of  the 
project . 


BATCH  FILES 

IMPUT  FILES  -  The  input  file  names  are  given  the 

extension  *.IN. 

OUTPUT  FILES  -  The  simulation  output  files  are  given  the 

extension  *0U. 

PRINT  FILES  -  The  print  files  have  been  given  the 

extension  *.PR. 

(This  would  allow  stobsequent  updates  of  the  input  files  to  be 
ntunbered  as  INI . . .  /  OUl . . . ,  PRl . . .  etc . ) 

DEFAULT  SETTINGS: 


Control  Record: 

(i)  The  output  option  selected  is  "O"  which 

provides  a  detailed  listing,  auid  high  level  of 
summary  information. 

(ii)  The  input  record  listing  option  selected  is 
"O”  which  prints  all  input  records. 

(iii)  The  composite  terminal  node  output  option 

selected  is  ”16"  which  assximes  family  mode  and 
intrafamily  tramsfer  of  histogram  data. 

(iv)  The  number  of  interactions  used  are  "10"  in 
the  demonstration  model  to  facilitate 
operation  in  the  debug  mode  if  required. 

(v)  The  composite  node  name  and  the  network  neune 
are  left  as  blanks . 

(vi)  In  the  man  identification  the  name  of  the 
corresponding  Data  Flow  Diagreim  is  used  as 
identification  for  the  network  description. 

Arc  Records: 

(i)  For  each  of  the  arcs  the  following  records  are 
provided: 

(a)  Master  Arc  Record 

(b)  Time  Distribution  Satellite 

(c)  Cost  Distribution  Satellite 

(d)  Performance  Distribution  Satellite 

(ii)  The  Distribution  Satellite  Records  are  created 
to  provide  a  uniform  statistical  distribution. 
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(iii)  The  default  values  used  for  the  minimum  and 
maximum  in  each  criteria  are: 

TIME  10.0  10.0 

COST  10.0  100.0 

PERFORMANCE  10.0  50.0 

Node  Records: 

(i)  Input  Logic  —  The  input  logic  for  the  nodes 
are  either  "INITIAL"  or  "AND". 

(ii)  Output  Logic  -  The  output  logic  has  been 
defaulted  to  "AND"  or  "TERMINAL". 

(iii)  The  output  option  indicator  auid  the  storage 
option  indicator  are  defaulted  to  read  "0" . 

(iv)  The  node  description  has  also  been  left  blank. 

(It  is  again  noted  that  the  user  can  change  the  default 
values  to  desired  values  as  identified  by  the 
particular  requirement  and  applications . ) 

DOCDMENTATION: 

With  every  project  report  APJ  will  be  providing  the 
following  doctiments  relating  to  the  VERT: 

(i)  A  VERt  network  diagraun  corresponding  to  a 
particular  data  flow  diagram. 

(ii)  A  print  out  of  the  VERT  network  inputs  for  the 
particular  data  flow  diagrauns. 

(iii)  A  floppy  disc  containing  the  sample  input,  print 
and  the  simulation  output  files  for  the  default 
VERT  network. 
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+  +  +  +  +  +  +  + 

70.  C18.0  NS.O  N8.0  1.0  SND  3YS/SDBSYS  CRH  CMPNT  DAIA>0S®  CH6S>PM/ILSMr 

71.  C18.0  DTIME  1  2  10.0  20.0 

72.  C18.0  DCOST  1  2  10.0  100.0 

73.  a8.0  DPERF  1  2  10.0  50.0 

+  +  +  +  +  +  +  + 

74.  C19.0  N7.0  NS.O  1.0  SEND  SYS/SDBSYS  OPERAI'L  CAPABILITY  TO  PM/ILSMT 

75.  C19.0  DTIME  1  2  10.0  20.0 

76.  C19.0  DCOST  1  2  10.0  100.0 

77.  C19.0  DPERF  1  2  10.0  50.0 

+  +  +  +  +  +  +  + 

78.  C20.0  N6.0  NS.O  1.0  SEND  RESOURCES  REQUIRB)  FOR  REPAIR  TO  402.2.4 

79.  C20.0  DTIME  1  2  10.0  20.0 

80.  C20.0  DCOST  1  2  10.0  100.0 

81.  aO.O  DPERF  1  2  10.0  50.0 

+  +  +  +  +  +  +  + 

82.  ENDARC 

+  +  t  +  +  +  +  f 

83.  Nl.O  12  0  0 

+  +  +  +  +  +  +  + 

84.  N2.0  2  2  0  0 

+  +  +  +  +  +  +  + 

85.  H3.0  2  2  0  0 

+  +  +  +  +  +  +  + 

86.  H4.0  2  2  0  0 

+  +  +  +  +  fi-  + 
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87.  H5.0  2  2  0  0 

+  +  +  +  +  +  +  + 
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88.  N6.0  2  2  0  0 

+  +  +  +  +  +  +  + 

89.  117.0  2  2  0  0 

+  +  +  +  +  +  +  + 

90.  N8.0  2  10  0 

+  +  +  +  +  +  +  + 

91.  ENiniODE 

1  2  3  4  5  6  7  8 
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0016  10 

SmUATE  CRITICAL  COCONENTS 

a.i 

iru  »2i 

1.0  (3T  TECHNICAL  DAIA/DRAHINGS  FROM  PM/DF 

Cl.l 

DTQS  1 

2  10.0 

20.0 

n.i 

DCOST  1 

2  10.0 

100.0 

CM 

DPERF  1 

2  10.0 

SO.O 

C2.1 

NIA  N2A 

1.0  GET  SELECTED  SYSTEM/EQDIPMENT  FOR  ANALYSIS 

C2.1 

DTIME  1 

2  10.0 

20.0 

C2.1 

DCOST  1 

2  10.0 

100.0 

C2.1 

DPERF  1 

2  10.0 

50.0 

□  .1 

H2A  H3A 

1.0  ASSESS  BATTLE  DAHAES  RESILIENCE 

C3.1 

DTIME  1 

2  10.0 

20.0 

a.i 

DCOST  1 

2  10.0 

100.0 

C3.1 

DPERF  1 

2  10.0 

50.0 

C4.1 

NU  N3A 

1.0  GET  FUNCTIONAL  REQUIRIMENTS  DATA  FR(»I  THE  AAF 

Cl.l 

OTOffi  1 

2  10.0 

20.0 

Cl.l 

DCOST  1 

2  10.0 

100.0 

Cl.l 

DPERF  1 

2  10.0 

50.0 

C5.1 

NIA  NBA 

1.0  GET  RELIABILITY  DATA  FROM  THE  HISTORY  FILE 

C5.1 

DTIME  1 

2  10.0 

20.0 

C5.1 

DCOST  1 

2  10.0 

100.0 

C5.1 

DPERF  1 

2  10.0 

50.0 

C6.1 

NBA  NIA 

1.0  IDENTin  CRITICAL  COMPONENTS 

C6.1 

DTIME  1 

2  10.0 

20.0 

C6.1 

DCOST  1 

2  10.0 

100.0 

C6.1 

DPERF  I 

2  10.0 

50.0 

CT.l 

NU  NIA 

1.0  GET  FUNCTIONAL  REQUIRBIENTS  DATA  FROM  THE  AAF 

C7.1 

DTIME  1 

2  10.0 

20.0 

C7.1 

DCOST  1 

2  10.0 

100.0 

CT.l 

DPERF  1 

2  10.0 

SO.O 

C8.1 

NIA  N5A 

1.0  DETERMINE  FUNCHON  LOST  DUE  TO  DAMAGE 

C8.1 

DTIME  1 

2  10.0 

20.0 

C8.1 

DCOST  1 

2  10.0 

100.0 

C8.1 

DPERF  1 

2  10.0 

50.0 

C9.1 

HSA  N6A 

1.0  SEND  CRmCAL  COMPONENTS  LIST  TO  PROCESS  BOB. 2 

C3.1 

oms  1 

2  10.0 

20.0 

CJ.l 

DCOST  1 

2  10.0 

100.0 

C9.1 

DPERF  1 

2  10.0 

50.0 

ENDARC 

HU 

12  0  0 

N2& 

2  2  0  0 

lOA 

2  2  0  0 

Mi 

2  2  0  0 

H5A 

2  2  0  0 

H6i 

2  10  0 

SDNODE 

D-10 


1 


HEW  HETWORK  PASl 

1  2  3  4  5  6  7  8 

12345678901234567890123456789012345678901234567890123456789012345678901234567890 


1.  0016 

10 

REPUR  MEIBODOLOGY 

+  + 

+ 

+  +  + 

+ 

+ 

2.  C1.2 

NIB  N2B 

1.0  GET  COMPONENTS  REPAIRABLE  IN  BAmE 

3.  a.2 

DIIHE  1 

2  10.0 

20.0 

4.  C1.2 

DCOST  1 

2  10.0 

100.0 

5.  C1.2 

DPEBF  1 

2  10.0 

50.0 

+  + 

+ 

+  +  t 

+ 

+ 

6.  C2.2 

N2B  N3B 

1.0  DETERMINE  REPAIR  METHOD  TO  BE  OSED 

7.  a.2 

DIIME  1 

2  10.0 

20.0 

8.  a.2 

DCOST  1 

2  10.0 

100.0 

9.  a.2 

OPERF  1 

2  10.0 

50.0 

f  + 

+ 

+  +  + 

+ 

+ 

10.  a.2 

NIB  N4B 

1.0  (an  MANPOWER  REQS  DATA  FROM  HISTRCL  INS?  E}{FERIENCE 

11.  a.2 

DTIHE  1 

2  10.0 

20.0 

12.  a.2 

DCOST  1 

2  10.0 

100.0 

13.  a.2 

DPQIf  1 

2  10.0 

50.0 

♦  + 

+ 

+  +  + 

+ 

+ 

14.  C4.2 

N3B  H4B 

1.0  DETERMINE  BEPLACQ4ENT  PROCEDORES 

15.  C4.2 

dths  1 

2  10.0 

20.0 

16.  C4.2 

DCOST  1 

2  10.0 

100.0 

17.  C4.2 

DPERF  1 

2  10.0 

50.0 

+  + 

+ 

+  +  + 

+ 

+ 

18.  C5.2 

N3B  H4B 

1.0  DETERMINE  MENDING  METHOD  &  PROCEDURE 

19.  a.2 

DTIHE  1 

2  10,0 

20.0 

20.  a.2 

DCOST  1 

2  10.0 

100.0 

21.  a.2 

DPERF  1 

2  10.0 

50.0 

+  + 

+ 

+  +  + 

+ 

+ 

22.  C6.2 

N3B  N4B 

1.0  DETERMINE  OTHER  REPAIR  METHODS  AND  PROCEDURES 

23.  C6.2 

DTIHE  1 

2  10.0 

20.0 

24.  C6.2 

DCOST  1 

2  10.0 

100.0 

25.  C6.2 

DPEBF  1 

2  10.0 

50.0 

+  + 

+ 

+  +  +■ 

+ 

+ 

26.  C7.2 

N3B  N4B 

1.0  DETERMINE  PROCEDURE  TO  BE  USED 

27.  C7.2 

DTIHE  1 

2  10.0 

20.0 

28.  a.2 

DCOST  1 

2  10.0 

100.0 

29.  C7.2 

DPEBF  1 

2  10.0 

50.0 

+  + 

+ 

+  +  + 

+ 

+ 

30.  a.2 

H4B  N5B 

1.0  IDENTIFY  REQUIRED  RESOURCES  FOR  REPAIR 

31.  a.2 

DTIHE  1 

2  10.0 

20.0 

32.  a.2 

DCOST  1 

2  10.0 

100.0 

33.  a.2 

DPERF  1 

2  10.0 

50.0 

+  + 

+ 

+  +  + 

+ 

34.  a.2 

N5B  N6B 

1.0  SEND  REVURED  RESOURCES  FOR  REPAIR  TO  402.2.4 

35.  a.2 

DTIHE  1 

2  10.0 

20.0 

36.  a.2 

DCOST  1 

2  10.0 

100.0 

37.  a.2 

DPERF  1 

2  10.0 

50.0 

+  + 

+ 

+  +  f 

+ 

+ 

38.  C10.2 

N5B  N6B 

1.0  SEND  COMPONENT  DATA  AFTER  REPAIR  TO  PROC  303.2.11.6 

39.  CIO. 2 

DTIHE  1 

2  10.0 

20.0 

40.  CIO. 2 

DaST  1 

2  10.0 

100.0 

41.  CIO. 2 

DPEBF  1 

2  10.0 

50.0 

+  + 

+ 

+  +  + 

+ 

+ 

42.  ENDARC 

+  + 

+ 

+  +  +• 

+ 

+ 

43.  NIB 

12  0  0 

+  + 

+ 

+  +  + 

+ 

+ 

1  2 

3 

4  5  6 

7 

3 
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44.  N2B  2  2  0  0 

+  +  +  +  +  +  +  + 

45.  H3B  2  2  0  0 

+  +  +  +  +  +  +  + 

46.  N4B  2  2  0  0 

+  +  +  +  +  +  +  + 

47.  N5B  2  2  0  0 

+  +  +  +  +  4  +  + 

48.  N6B  2  10  0 

+  +  +  +  +  +  +  + 

49.  ENDNODE 
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ANNEX  E 


MOTS: 


ANNEX  E 

STRUCTURED  SYSTEMS  ANALYSIS 
Fundamentals 


structured  Systems  Analysis  (SSA)  has  recently  become  am 
industry  stamdard  for  generating  Data  Flow  Diagrauns  (replacing 
"logic  diagrams"  or  "flow  charts")  to  aid  in  coordinating  the 
functions  to  be  performed  by  a  computer  prograuti  amd  its 
associated  Inputs/Outputs  (I/O) .  During  the  SSA,  each  set  of 
"flow  charts"  can  be  checked  by  the  potential  user  to  assure 
that  there  is  complete  agreement  on  what  is  to  be  done  by  the 
program,  and  how  it  is  to  be  accomplished.  It  also  provides 
considerable  flexibility  for  updating  or  chamging  the  prograun. 

Six  basic  elements  (  see  figure  1)  are  used  in  SSA: 

1 .  Process  (PRC) 

2.  Data  Flow  (DAF) 

3.  Data  Store  (DAS) 

4 .  External  Entity  (EXT) 

5.  Data  Flow  Diagram  (DFD) 

6.  Data  Dictionary  (DCT) 

PROCESS  (Represented  by  a  Circle) : 

A  function  or  operation  to  be  performed  which  caun  be 
explained  by  a  set  of  instructions  representing  a  single  task, 
e.g.,  "calculate  interest  on  a  loam",  "prepare  a  draft  report". 
If  the  Process  description  is  too  complex  to  describe  in  a  few 
steps,  it  may  be  necessary  to  develop  a  lower  level  description 
(see  below) . 

DATA  FLOW  (Lines  interconnecting  Processes  or  I/Os) : 

Each  function  or  Process  cannot  be  a  stand-alone  in  a 
complex  network.  To  have  amy  meaning  in  a  program,  each  process 
must  be  initiated  by  a  previous  action  and/or  provided 
information  on  which  to  act.  Furthezrmore,  a  Process  must  result 
in  am  output  which  is  the  input  to  the  next  logical  Process . 
These  inputs,  outputs,  or  initiating  actions  are  identified  as 
Data  Flows,  and  are  represented  by  the  Data  Flow  lines 
indicating  its  point  of  origin  and  the  process  to  which  it 
provides  data. 
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DATA  STORE  (Represented  by  two  parallel  lines) : 

Although  some  Processes  generate  data  used  as  input  to  a 
succeeding  Process,  there  is  often  a  need  to  "gather  or  collect" 
information  from  files  in  which  it  is  stored.  This  information 
may  come  from  an  external  source  (such  as  a  MIL-STD,  Army 
regulation,  historical  experience  files,  etc.),  or  an  internal 
source  or  file  in  which  data  is  temporarily  stored  for  use  by 
succeeding  processes .  These  Data  Stores  can  be  visualized  as  a 
"file  cabinet",  in  which  the  data  are  stored  for  later 
retrieval) . 

EXTERNAL  ENTITY  (Represented  by  a  Rectangle) : 

Each  program  or  logical  process  must  have  aui  initiating 
action,  a  "point"  of  disposition  of  the  results,  and  possible 
input  guidamce  or  instructions.  Each  of  these  have  authorities, 
functions,  or  applications  which  are  independent  of  the  program 
Process  (although  required  by  the  program  Process) .  Thus,  these 
activities,  agencies,  or  facilities  are  considered  "External 
Entities"  to  the  program. 

DATA  FLOW  DIAGRAM: 

» 

The  general  arrangement  of  the  above  can  be  readily  seen. 
First,  the  circle  or  Process  describes  what  has  to  be  done;  the 
interconnecting  lines  represent  the  Data  Flows,  together  with 
the  specific  description  of  all  I/Os.  The  Data  Stores  identify 
the  source  and/or  file  designation  of  a  data  base,  and  the 
External  Entities  represent  those  activities  remote  from  the 
Process,  which  are  the  source  of  guidance  or  the  recipients  of 
the  program.  This  combination  of  Processes,  Data  Flows,  Data 
Stores,  euid  External  Entities  constitutes  a  "Data  Flow 
Diagram" .  The  unique  feature  of  the  Data  Flow  Diagrem  (DFD)  is 
that  each  process  can  be  considered  independently,  permitting  a 
change  to  be  made  in  one  Process  without  a  major  change  in  the 
overall  program. 

DATA  DICTIONARY: 

The  Data  Dictionary  consists  of  a  complete  description  of 
each  of  the  basic  elements.  For  the  Process,  it  contains  a 
step-by-step  description  of  what  has  to  be  performed.  The 
description  of  the  Data  Flow  identifies  the  nomenclature  of  the 
data,  a  detailed  description  of  its  content,  and  its  source. 
The  Data  Stores  and  External  Entities  are  described,  including 
possible  location. 
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The  Data  Dictionary  (a  living  docxament)  begins  with  a 
description  of  the  first  Process  and  is  continually  built-up  as 
the  Data  Flow  Diagrams  are  expanded,  detailed,  and  eventually 
completed. 

APPROACH  TO  PERFORMING  STRUCTURED  SYSTEM  ANALYSIS: 

The  best  approach  to  Structured  Systems  Analysis  is  to 
assTome  that  the  prograim  consists  of  a  series  of  processes,  each 
of  which  are  to  be  assigned  to  an  inexperienced  analyst .  Each 
analyst  is  to  be  walked  through  the  assigned  process  of  the 
P«toq>rafii4n<H*ririaM  itLaage  sltapb^ypatfipumed  or  what  actions  have  to  be 
taken  to  accomplish  the  process.  The  auialyst  is  also  informed 
where  the  information  is  coming  from  (input  Data  Flow) ,  what  is 
to  be  generated  by  each  process  (output  Data  Flow) ,  where  the 
data  base  may  to  be  found  (Data  Stores) ,  and  who  to  contact  for 
guidauice  (External  Entities)  . 

The  best  way  to  initiate  a  SSA  is  to  set  down  the  point  of 
origin  of  a  progreun,  its  final  goal  (s)  ,  and  the  intermediate 
functions  or  actions  needed  to  get  from  beginning  to  goal .  Each 
step  should  be  considered  as  a  Process  -  some  may  be  sequential 
and  others  parallel.  Then,  the  steps  needed  to  accomplish  the 
Process  should  be  described.  If  the  description  is  complex  and 
needs  inteirmediate  steps,  the  Process  is  then  a  candidate  for  an 
"explosion".  That  is,  the  top  (or  upper)  level  Process  is 
considered  as  a  "project”  and  its  own  Data  Flow  Diagram  is 
prepared . 

When  writing  the  step-by-step  procedures  in  the  Process, 
certain  elements  of  data  (or  information)  must  be  made  availedjle 
for  the  procedure.  Each  element  of  data  is  considered  as  an 
input  Data  Flow,  which  is  identified  and  described.  The 
product  (or  result)  of  a  Process  is  eui  output  Data  Flow  element. 

Each  Data  Flow  to  the  Process  must  originate  from: 

1 .  an  earlier  Process 

2.  a  Data  Store  (or  file) 

3  .  2U1  External  Entity . 

These  sources  are  also  identified,  described  auid  put  into 
the  Data  Dictionary.  As  soon  as  the  last  portion  of  the  Data 
Flow  Diagram  has  been  described,  the  SSA  is  complete . 
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The  structured  Analysis  phase  is  followed  by  Structured 
Design,  then  by  programming  and  finally  software  test  and 
validation.  The  organization  of  Structured  Analysis  and  its 
relationship  to  Structured  System  Design  is  shown  on  Figure  2 . 
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Interface  REVIEW/CRITIQUE/ACCEPTANCE  OF  DFD 


Figure  1.  Structured  Analysis  &  Structured 
Systems  Design  Organization 
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REPRESENTS  A  PROCESS,  FUNCTION 
OR  ACTION 


REPRESENTS  A  DATA  STORE  OR  A 
DATA  FILE  -  OFTEN  IDENTIFIED  AS 
A  REPOSITORY  OF  INFORMATION  OF 
A  SPECIFIC  TYPE 


REPRESENTS  A  DATA  ELEMENT 
FLOW  INDICATING  OUTPUT  FROM 
ONE  PROCESS  AND  INPUT  TO 
ANOTHER  PROCESS 


REPRESENTS  AN  EXTERNAL 
ENTITY  -  AN  ACTIVITY  NOT  A 
PART  OF  THE  SYSTEM/PROCESS 
BEING  MODELED. 


Figure  2 .  Standard  DFD  Symbol  Definitions 
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